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Abstract 

Distributed Space Missions (DSMs) are gaining 
momentum in their application to earth observation 
missions owing to their unique ability to increase 
observation sampling in multiple dimensions. DSM 
design is a complex problem with many design 
variables, multiple objectives determining performance 
and cost and emergent, often unexpected, behaviors. 
There are very few open-access tools available to 
explore the tradespace of variables, minimize cost and 
maximize performance for pre-defmed science goals, 
and therefore select the most optimal design. This 
paper presents a software tool that can multiple DSM 
architectures based on pre-defmed design variable 
ranges and size those architectures in terms of pre- 
defined science and cost metrics. The tool will help a 
user select Pareto optimal DSM designs based on 
design of experiments techniques. The tool will be 
applied to some earth observation examples to 
demonstrate its applicability in making some key 
decisions between different performance metrics and 
cost metrics early in the design lifecycle. 

1. Introduction 

Distributed Space Missions (DSMs) are gaining 
momentum in their application to Earth Observation 
(EO) missions owing to their unique ability to increase 
observation sampling in spatial, spectral, angular and 
temporal dimensions simultaneously. Spatial resolution 
of an image can be increased by using multiple 
satellites in formation flight to synthesise a long 
baseline aperture as shown for optical 
interferometry[l] and synthetic aperture radars. 
Constellations of evenly spaced satellites on repeat 
track orbits ensure temporal sampling within a few 
hours as well as continuous coverage maintenance. 
Spectral sampling can be improved by fractionating the 
payload (fractionated spacecraft) such that each 


physical entity images a different part of the spectrum 
and has customized optics to do so. Angular sampling 
or the ability to look at the same point on the ground at 
different angles (for reflectance studies or navigation) 
improves by flying many satellites in formation[2] . 
Radiometric resolution depends on the resolution of the 
other sampling dimensions for a fixed instrument mass 
and complexity. Since DSMs allow sampling 
improvement in any dimension by increasing number 
of satellites in place of their individual sizes, 
radiometric resolution can be improved without 
compromising on other science sampling requirements. 

Since traditional single satellites are called monolithic 
systems, DSMs can be considered homogeneous or 
heterogeneous combinations of monoliths. They 
include homogenous and heterogeneous constellations 
such as the Global Positioning System and A-Train 
respectively, autonomous formation flying clusters 
such as PRISMA, fractionated spacecraft such as the 
recently canceled System F6 Program[3] and 
cellularized systems such as the DARPA Phoenix 
Program[4]. Formation flight, as required in clusters, 
fractionation or cellularization, entails active control of 
the individual spacecrafts in order to maintain relative 
distances, orientations and geometry [5]. Fractionated 
spacecraft have the different spacecraft subsystems 
distributed over the physical entities and they exchange 
data, power and telemetry among each other (Figure 1- 
right). Cellularized systems are formed by assembling 
on-orbit resources called satlets to make aggregate but 
distributed systems. 
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Figure 1 : Examples of distributed space systems - 
GPS or homogeneous constellation on the left and 
F6 or a fractionated spacecraft exchanging 
resources on the right. 

Since DSM architectures are defined by monolithic 
architecture variables and variables associated with the 
distributed framework, it leads to a large number of 
design variables. The number increases further in 
heterogeneous cases. DSMs are also expected to 
increase mission flexibility, scalability, evolvability 
and robustness as well as to minimize costs and risks 
associated with launch and operations. As a result, 
DSM design is a complex problem with many design 
variables, multiple objectives determining performance 
and cost and emergent, often unexpected, behaviors. 
There are very few open-access tools available to 
explore the tradespace of variables, minimize cost and 
maximize performance for pre-defmed science goals, 
and therefore select the most optimal design. 

2. Decisions in Space System Design 

Space Systems are one of the most complex 
engineering systems designed by man and designing 
them. Designing them is not only technically 
challenging but also involves making hundreds of 
decisions early in the design cycle for allocating 
limited resources across the system and optimizing 
performance and cost. EO performance can be 
simplistically represented by spatial resolution, spatial 
range (swath, coverage), spectral resolution 

(wavelength bandwidth), spectral range (spectrum 
covered), angular resolution (number of view and solar 
illumination angles for the same image), angular range 
(spread of those angles), temporal range (mission 
lifetime), temporal resolution (repeat or revisit time), 
radiometric range (number of bits) and radiometric 
resolution (bits, signal to noise ratio). 

2.1. Monolithic Systems - Traditional 

Decisions in monolithic systems include but are not 
restricted to allocations of resources such as mass, 
power and volume among different subsystems. For 
example, stable imagery of the Earth requires better 
pointing control which requires better attitude control 
systems therefore more mass, power and cost. High 
resolution images need higher downlink capacities, 


which in turn need bigger antennas and bandwidth. 
Onboard storage and processing capabilities can relieve 
communication requirements but at the cost of bigger 
and better processors. Longer lifetimes for satellites 
save on development and launch costs for follow-on 
missions and ensure continued science, however need 
more reliable electronics and radiation hardening either 
using thicker aluminum or code. More mass and power 
to orbit translates to development and launch costs. 
Since better images, as those indicated above, as direct 
metrics of Earth Observation performance, it needs to 
be traded against increasing need for resources. 

Conflicting trade-offs seen and associated decisions are 
required not only among subsystems but also choice of 
an orbit for the satellite. Lower altitude orbits provide 
more spatial resolution because of smaller pixels but 
lower temporal resolution because the orbital velocity 
is slower. Increasing the instrument field of view 
(FOV) increases global coverage but more than 15 deg 
FOV causes angular resolution to be too coarse for 
earth science applications [6]. Larger FOV allows 
frequent revisits but has no direct affect on repeats, 
which is a function of altitude and inclination only. 
Repeat period is the time to visit the same ground spot 
at exactly the same look angle while revisit is to visit 
the same at any look angle. Polar orbits allow global 
coverage and also the possibility of regular solar 
illumination essential for many earth science 
applications (called sun synchronicity) however 
equatorial orbits allow frequent revisits of the tropical 
regions. Sun synchronous orbits also allow far less 
launch flexibility than regular orbits. Therefore, orbit 
inclination choices are also a quantitative decision. 

2.2. Distributed Systems - Revolutionary 

Distributed systems have all the trades associated with 
monolithic systems and more associated with the 
network. Extra design variables include but are not 
restricted to the number of satellites and their 
individual masses, their orbits and inter-satellite 
spacing, existence and nature of inter- satellite 
communication and downlink schedules. These 
variables directly impact performance and cost. 

Performance variables, as defined earlier, can be 
mutually conflicting across the spatial, spectral, 
temporal, angular and radiometric dimensions and 
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within each dimension. For example, most earth 
observation satellites are put in repeat ground track 
orbits so that the same point on the Earth is revisited 
regularly and frequently. Obviously, more frequent 
revisits imply that the rotation of the Earth and the 
orbit has to be adjusted in such a way that the satellite 
comes back to the same spot frequently, and as a result 
has less time to visit similar spots on other longitudes. 
Therefore, global spatial coverage or spatial range and 
temporal resolution are conflicting metrics. Both can 
be improved by increasing the swath of satellite or the 
size of any instantaneous ground image. However, for 
a given number of pixels in an image, increasing its 
size or swath with increase the size of the pixels and 
coarsen resolution. Therefore, spatial range and 
temporal resolution are both conflicting metrics with 
respect to spatial resolution. Design variables need to 
be permuted to consider architectures that trade these 
metrics for an optimal design. 

-♦-Swath = 30km, Repeat = 2 days -"-Swath = 30km, Repeat = 4 days -"-Swath = 30km, Repeat = 8 days 
-♦-Swath = 50km, Repeat = 2 days -"-Swath = 50km, Repeat = 4 days -"-Swath = 50km, Repeat = 8 days 
-♦-Swath = 100km, Repeat = 2 days -"-Swath = 100km, Repeat = 4 days^-Swath = 100km, Repeat = 8 days 
300 | 



Number of Satellites (Plane independent) 
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-♦-Swath = 100km, Repeat = 2 days -"-Swath = 100km, Repeat = 4 days -"-Swath = 100km, Repeat = 8 days 
350 | 



Figure 2: Trade-off between the number of satellites 
(X-axis), spatial coverage at the Equator (Y-axis), 
spatial resolution (function of swath, shown in 
colors), temporal resolution (repeat period shown in 
marker shapes) and altitude (top: 780km, bottom: 
350 km). Thick black line indicates full equatorial 
coverage. 


Figure 2 shows the results of spatial coverage at the 
equator as a function of the number of satellites in the 
constellation, temporal resolution (repeat time of 2, 4, 8 
days) and spatial range (swath of 30, 50, 100 km) for a 
Walker constellation deployed at the altitude of the 
Iridium Comm Constellation or 780 km and the 
International Space Station (IS S) or 350 km. Only the 
architectures below the black line achieve full global 
coverage. For example, for a 50 km swath and 8 day 
repeat (blue triangles), a minimum of 7 and 6 satellites 
is needed respectively. If spatial resolution can be 
compromised to half and swath 100 km is allowed, 
then the same number of satellites can provide a 4 day 
repeat (double temporal resolution). 

Since the above coverage analysis is performed only at 
the Equator, the trade-off is linear. Revisit time is 
independent of the constellation arrangement hence 
very simple, unlike other temporal metrics. Global 
coverage analysis over the full latitude-longitude grid 
is non-linear, not as predictable and is an example of 
only one conflicting trade-off between the different 
performance dimensions in Earth Observation. There 
are many other complex decisions that will be 
discussed in detail in Section 3 and 5, hence the need 
for a comprehensive trade tool. 

3. Software Tools for SpaceSystem Design 

Computational tools for spacecraft and system design 
have been very important in making early design 
decisions. Model-based systems engineering is a focus 
of the INCOSE working groups and the developed 
tools have been applied to existing missions such as 
RAX[7] and PHOENIX[4]. Tools for space logistics 
and interplanetary transportation such SpaceNET, 
modular and open source, are also available[8]. The 
Cube SAT standard and associated documentation also 
provides an excellent resource to develop and integrate 
anything upto 3U (4 kg) spacecrafts [9]. 

3.1. Existing Tools in Distributed Space Missions 

Existing tools for monolithic spacecraft and other space 
design can be and have been adapted for distributed 
space systems. Individual components of space system 
design can be combined from different softwares. For 
example, orbit design can be done using NASA 
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GSFC’s GMAT tool or NASA JSC’s Copernicus tool. 
Spacecraft operations can be aided by NASA JPL’s 
APGEN, ASPEN or Maestro tools. Specific interfaces 
for risk and science return for Saturn and Mars 
missions are also available. Tools for specific science 
data analysis such as USGS’s ISIS and ESA’s Rosetta 
Science Planning tool can be modified for some 
mission design. Cost and risk associated with 
distributed launches, staged deployment and 
reconfigurable constellations, all of which allow 
flexible design but also increased costs, have been 
academically studied at MIT[10], [11]. 

3.2. Need for a new Tool for Earth Observation 

While all the above tools are great for specific missions 
and specific components, there is no off-the-shelf, 
modular tool for DSM design that can be used at the 
high-level architecture phase when key decisions are 
made. With the advent of hundreds of small sats in 
orbit currently and companies such as PlanetLabs and 
Skybox launching constellations in dozens, there is 
need for an integrated and modular tool which will 
modify MBSE for DSMs and enable easy plug into 
science metrics such as those for earth observation 
(extendable to astrophysics or navigation, etc.). Such a 
tool will allow rapid simulation of hundreds of 
architectures and their valuation so that the “best” ones 
can be selected early in the design cycle. 

4. Description of a New Software Tool for 
Distributed System Design 

We are currently developing a software tool, developed 
on the MATLAB engine interfaced with Systems Tool 
Kit or STK[12], that is based on tightly coupled 
science and engineering models. The orbits module can 
generate multiple DSM architectures based on pre- 
defined design variable ranges and size those 
architectures in terms of pre-defmed science and cost 
metrics. Design variables include but are not restricted 
to mission lifetime, constellation type, chief orbit of the 
formation, differential orbital elements in a formation, 
FOV of instrument, altitude, latitudes or regions of 
interest, inclination, planes and satellite numbers. 
Intermediate performance metrics include number of 
accesses, revisit time, coverage access and angular 
coverage at every point of the Earth’s grid as well as 
average values. The payload module interfaces with the 


orbits and control modules and has been described in 
detail in [13]. Design variables include ground pixel 
size, look and solar angles, altitude, wavelengths, pixel 
numbers, spectral elements, wavebands, pointing 
errors. Final performance metrics, based on science 
goals, are a function of the intermediate metrics. The 
tool will help a user select Pareto optimal DSM designs 
based on design of experiments techniques. 

Model-Based Systems Engineering (MBSE) has 
demonstrated success in small satellite design[7] in 
trading conflicting design variables and is a useful tool 
for pre-Phase A DSM design. MBSE may be extended 
to DSM design since it is a function of a much larger 
number of variables than its monolithic counterparts as 
well as has higher costs, and thus imperative to 
understand the trade-offs and interdependencies among 
the variables early in the design stage. In the traditional 
sense, observing system simulation experiments 
(OSSE) are used to quantify the impact of observations 
from future observation systems such as satellite 
instruments or ground-based networks on e.g. weather 
forecasts, by mimicking the process of data 
assimilation. In land or atmospheric applications alike, 
they have been used to validate science return for 
proposed instruments and therefore tweak their designs 
better. 

Our tradespace sofware tool combines the MBSE 
approach with the OSSE approach. The tool 
enumerates dozens of architectures with different 
combinations of the design variables. Constraints may 
also be added; For example, altitude-inclination 
combinations as available for easy commercial 
launches or spectral elements/detectors as available 
within specific organizations^ 3]. The tool has 
previously been applied to formation flight design for 
angular reflectance measurements to estimate bi- 
directional reflectance distribution functions [2], [14], 
global earth radiation budget estimations[15] and 
snapshot imager selections for angular acquisition^ 3]. 
The tradespace of designs can be analyzed by varying 
the variables in the MBSE model and assessing its 
effect on data assimilation and science products using 
OSSEs. This paper introduces only the architecture 
enumeration and technical metrics (which serve as 
inputs to the OSSE models) of the tool and discusses 
their applicability in making design decisions. 
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Decisions are obviously more refined when the OSSE 
component and science impact is considered, as shown 
in separate literature for constellations[15] and 
formation flight[2]. 

4.1. Spatial and Temporal Sampling 

Spatial coverage and sampling is a product of the orbits 
module, given inputs from the payload module (for 
pixel sizes and spectrometer type). Parameters such as 
the grid size on the earth (default: 5degX5deg in both 
latitude and longitude) and time sampling (default: 1 
minute) can be defined. Using the required 
characteristics, automatic scripts on MATLAB drive 
STK to generate multiple architectures on STK by 
permuting the orbit design variables. Three 
architectures are pictured in Figure 3’s left column. 
MATLAB -driven STK commands each architecture to 
generate a full access report as a .cvaa file, many of 
which are seen in Figure 3’s second column. The 
reports are named in keeping with the design variables 
for easy post-processing. For example, the first one is a 
1 plane, 1 satellite (monolithic) design at a 400 km 


instrument field of view with latitudes of interest below 
40 deg. Each access report is a detailed text file - 
Figure 3 third column - containing the time period 
(from when to when) at which every grid point is 
accessed by every sensor. The file is post-processed to 
provide customized temporal metrics such as revisit 
time, time for first access, number of accesses, time for 
global coverage, etc. for every grid point and the globe. 
Science metrics dependent on such temporal metrics 
can easily be calculated by plugging in another module, 
modeled after an OSSE. Since the analysis is global 
and across any length of mission lifetime, the metrics 
calculated are spatial and temporal. 

A separate script is also available for analyzing specific 
grid points in the same way as above, thus saving the 
computational resources required for full global 
analysis. For any target location or ground station, a 
text access report is automatically generated by 
MATLAB -commanded STK and automatically 

repeated for many architecture. Each generates an 
access report, which can be post-processed to generate 
customized metrics as described above. 


altitude and 60 deg inclination with a 15 deg 
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Figure 3: Process Flow for Temporal Metric calculation globally or specific areas or latitudes of interest. 


4.2. Angular or Customized Sampling 

STK, without the parallel processing license and 
dozens of available cores, was found to be inefficient 
for architecture studies using customized metrics. 
Angular coverage will be discussed as a case study, 
because it is a new area of interest owing to the need of 
measuring Earth reflectance at different angles for 
products such as albedo and total outgoing radiation. 
For angular sampling metrics, the following angles are 


required to be calculated at every grid point and time 
instant for every architecture: measurement zenith 
angle or MZA for each satellite (angle between the 
satellite vector at the ground spot and the zenith; <90 
deg), solar zenith angle or SZA (angle between the sun 
vector at the ground spot and the zenith; <90 deg for 
solar spectrum) and relative azimuth angle or RAZ 
(angle on the horizontal between the satellite vector 
projection and sun vector projection at the ground spot; 
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<360 deg). The number of calculated angles is the 
product of the number of ground points (1651 by 
default), number of satellites, number of angles (3 by 
default), number of architectures and number of time 
steps (1441 if in minutes, for just one day). The only 
way to calculate all of them is using a tool called Grid 
Inspector which loops over the number of points, 
satellites and angles, and re-calculates access for all 
loops, therefore taking 5 days to compute only 1 angle 
for a 64 satellite constellation. 

To improve efficiency, our tool restricts the use of STK 
for customized metric calculations outside of temporal 
and spatial analysis. First, the High Precision Orbit 
Propagator (HPOP) using the Jaccia-Roberts 
Atmospheric Model as upto J4 terms is used to 
propagate the orbits for all satellites in every 


architecture and the resultant states per time step saved 
as text files. Second, the access reports for all 
architectures - as seen in Figure 3 - are saved for exact 
global coverage. Third, the grid point information is 
saved. These three outputs from STK are then post- 
processed to calculate the required hundreds of 
thousands of angles offline. The results are validated 
against those calculated by STK’s Grid Inspector for 
one satellite propagated over one day. A reasonably 
good fit is seen for all grid points and all times with 
less than 5 deg of average error. This error is less than 
half the angular resolution available by a grid and time 
resolution of 5 deg and 1 min, for a satellite ground 
velocity of 7.3 km/s, hence considered negligible. All 
sampled angles and their dependent metrics, or any 
other customized metrics dependent on global or 
temporal coverage, will be calculated in the above way 



Number of minutes of satellite propagation 



Figure 4: Validation of the solar illumination and view angles calculated by the proposed tool (blue) at every 
grid point and time instant those calculated by the Systems Tool kit (red). The top panel shows one angle as 
seen by a single satellite at every minute for a day while the bottom panels show all three angles over a 22 
minute period, for better visualization. Average error is <5 deg, negligible compared to the grid resolution of 
5 deg and time resolution of 1 min, for a satellite ground velocity of 7.3 km/s. 
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4.3. Others - Spectral Sampling , Cost , Risk 

Performance of any architecture is also determined by 
the extent of spectral sampling in the image - both 
spectral range or the amount of spectrum and spectral 
resolution or the width of each wavelength band. All 
the performance metrics of every architecture are then 
compared to the cost and risk of development and 
operations to make a Pareto optimal decision. 

The spectral sampling trades are primarily a 
function of the payload of the satellite and the type of 
spectrometer or radiometer being used. The payload 
model[13] is a MATLAB -based tool that calculates the 
effect of the design variables on optical system 
requirements such as detector pixels, focal plane size, 
focal length, aperture diameter and eventually on 
system metrics such as signal to noise ratio (SNR), 
swath and number of wavebands possible. The metrics 
are conflicting in themselves hence decisions on the 
design must be made after considering the trade-offs 
between the metrics. The payload model is inherently 
dependent on the types of available spectral elements, 
and has been described in detail in [13]. Examples of 
some trade-offs will be shown in the next section. 

The cost model is discussed in detail in [11]. Its 
development has been challenging due to the 
unavailability of enough data on pricing the cost of 
multiple copies of the same unit as well as operations 
cost of a complex multi-disciplinary system. 


5. Example Applications of the Tool 

The described tool for designing distributed space 
systems is applied to a few candidate examples in earth 
observation to demonstrate its utility in making 
decisions after due consideration to multiple 
conflicting objectives of performance i.e. spatial, 
spectral, angular and temporal sampling, and cost. 

5.1. Temporal vs. Spatial Trade-Off 

A simple example of temporal vs. spatial trade-off at 
the Equator was seen in Figure 2. If revisit time is 
considered as a metric instead of repeat time, the 
calculations are more complicated because revisit is a 
non-linear and non-analytical function of orbits of 
satellites, their relative arrangement, payload FOV and 
geographic location of the points on Earth. 

A Walker constellation with varying number of 
satellites (arrangement not considered because it does 
not affect revisit time as long as uniformly arranged) 
and FOVs were simulated for a constant altitude of 709 
km and inclination of 98.18 deg, in keeping with the 
orbit of the A-Train and EOS satellites. Only latitudes 
below 70 deg were considered. Figure 5 shows the 
maximum revisit time provided by all the architectures. 
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Figure 5: Results from our temporal trade tool using Revisit time as a metric. [Left] Maximum revisit time 
over all gridpoints as a function of payload FOV and number of satellites in a Walker constellation at 709 km 
altitude, 98.18 deg inclination. The thick black line indicates at least a 24 hour revisit for any point and the 
black circles indicate the designs for which global revisit time is shown on the right. [Right] Average revisit 
time at every grid point, calculated over a 16 day period, for a 1 (top) and 16 (bottom) satellite constellation. 


The current monolithic spacecrafts with 15 deg FOV 
(e.g. Landsat) provide a 350 hour revisit - black circle 
on Figure 5’s left and full global map on Figure 5’s 
right top. The results show that at least 14 such 
satellites are required for a daily revisit (Figure 5 black 
line) and 16 satellites for a daily repeat (analytical 
calculation). By doubling the FOV to 30 deg allows the 
same revisit in about quarter the satellites (4 satellites). 
The right panel also shows that revisits are far more 
frequent at higher latitudes than lower ones for polar 
constellations. While revisit time does not depend on 
constellation arrangement, metrics such as time 
required for full global coverage does. Figure 6 shows 
the time taken for the last grid point on the globe is 
accessed by different constellation architectures. The 
results from our tool show that global coverage is faster 
if the same number of satellites are arranged in more 
planes. In fact, lesser number of satellites (e.g. 8 
satellites in red vs. 12 satellites in grey) can achieve 
coverage faster if arranged in more planes. The trade- 
off however is in terms of cost because launching into 
8 planes requires 8 times more fuel or needs 8 times the 
number of launches than launching into 1 plane. The 
increased performance and cost saved in developing 4 
extra satellites can be compared against the cost of 
launching into 8 instead of 1 plane for the optimal 
design decision. 



Figure 6: Time required to global coverage for 
Walker constellations (at 709 km, 98.18 deg) with 
varying number of satellites and their planar 
arrangement. Walker Delta constellations, on an 
average, show lesser time than Walker Star. 

The 8 satellite arrangement can be further analyzed by 
plotting the timeline of global access (until 100% is 
accessed) - Figure 7. Walker Delta arrangements are 
seen to be better than Walker Star in time to global 
access and all curves are compared to the monolithic 
counterpart in the same orbit. The monolith takes 14 
days for full global access as seen earlier and is shown 
with a black line, called ‘Landsat’ because it is an 
existing spacecraft in the same orbit with a 16-day 
repeat cycle. Figure 7’s curves are very useful in 
deciding which design to choose depending on the 
integration time available over measurements and the 
coverage flexibility. For example, if a 2 day integration 
time is available, then the 8 plane constellation is 
equivalent to having continuous global coverage and 
there is no value in adding more satellites. Our tool 
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can be used to select a design, given a required 
temporal resolution, spatial coverage and budget. 



Figure 7: Percentage of the globe covered with 
respect to time for Walker constellations (at 709 km, 
98.18 deg) with 8 satellites arranged in different 
planes (colors) and in Delta (continuous line) or 
Star (dotted line) arrangements. 


5.2. Angular vs. Spatial Trade-Off 

Angular coverage is achieved by looking at the same 
ground spot at different angles using multiple satellites 
and at different sun illumination angles. For the same 
set of optics, increasing look angles causes the ground 
spot to increase in size and spatial resolution to coarsen 
trigonometrically[13]. This angular effect and coarse 
resolution is also the reason that most EO satellites 
such as Landsat guard against their FOV exceeding 30 
deg[6]. Since the diffraction limited aperture diameter 
of the payload and its associated focal length increases 
with finer spatial resolution and higher altitudes, a 
design decision based on informed trade-offs is critical. 
Larger optics need larger space structures and increase 
costs. Figure 8 shows the minimum required payload 
diameter as a function of the above variables. Focal 
length for a shutter F# of 1.5 has been contoured. Such 
results from the tool help decide on the design of 
optics, given a required range of angular range, spatial 
resolution (GSD) and spacecraft chassis constraints. 

Spatial range or swath, as seen in Figure 9, is a 
function of slant height from the ground pixel to the 
aperture, number of pixels and the type of spectrometer 
used. Slant height is affected by altitude and look 
angle as contoured in Figure 9. Spectrometer 
dependence is analyzed by comparing two types of 


spectrometers: AOTF and WG. AOTFs are tunable 
filters which take 2D spatial images at every instant 
and sample the full spectral range in time, as the 
aperture remains exposed to the ground spot. Thus, all 
the pixels on the AOTF FPA are available for spatial 
imaging because the spectral signal is extracted 
temporally, but the total number of pixels for the 
AOTF spectrometer is severely restricted to allow for 
imaging and readout of all spectral bands (86 in Figure 
9). A waveguide (WG) spectrometer uses optical 
waveguides to extract the spectral content of each pixel 
in the 2D image so the total pixels on the WG FPA are 
shared between 86 spectral bands and actual spatial 
pixels, limiting the swath. The trade-off between 
spatial range, angular range and pixel number is 
apparent from the results and helps make a design 
decision. AOTFs provide less than a third of the swath 
compared to WGs so Figure 9 scales down by a third. 


Log10(Required Aperture Diameter) in cm at h = 800 km 



200 300 400 500 600 700 800 900 1000 

Ground Pixel Size in metres 




Figure 8: Variation of required aperture diameter (as 
loglO) at altitude = 800 km as a function of look 
angle to the image and ground resolution. The 
corresponding required focal length and the slant 
distances are contoured. Lower altitudes need 
lower diameters and focal lengths (not shown). 


Swath available in km for FPA pixels# = 2000 2 /86 wavebands 



Altitude of orbit in km 
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Figure 9: Simulated swath for a WG spectrometer 
as a function of a given number of FPA pixels - 
marked on top and arranged differently for each 
spec, look angles to the image and altitude. More 
pixels provide more swath and the AOTF spectral 
extraction mechanism less swath (both 
dependences not shown for compactness). 


5.3. Spatial vs. Spectral Trade-Off 

As was apparent from the previous discussion, either 
the imaging and read out time (AOTFs) or the FPA 
pixels (WGs) need to be shared between the spatial and 
spectral content of any image, thus leading to 
conflicting performance metrics and the need to make a 
decision between them. 


SNR at sensor for wl = 1010 nm, SZA= 0, VZA= 0, h = 800 km 



200 300 400 500 600 700 800 900 1000 

Ground Pixel Size in metres 


Figure 10: Simulated SNR for AOTFs as a function 
of spectral wavebands and ground resolution 
required to be imaged for a nadir looking satellite at 
800 km, wavelength of 1010 nm and solar incidence 
at noon. The contours represent achievable swath 
(thick black) and effective number of spatial pixels 
available on the FPA (thin black), calculated 
dynamically to maximize swath for at least 5% 
image integration time. 

In order to operate within nominal radiometric 
resolutions, spectral range and spatial range will need 
to be traded off among each other. Our tool provides 
more quantitative estimates of the signal to noise ratio 
(SNR) for this purpose as seen in Figure 10[13] (only 
AOTF shown for compactness). Dependence of SNR 
on spatial range (swath), resolution (GSD), spectral 
resolution (wavebands), angular range (SZA,VZA=0 
shown only) and altitude is seen. The tool’s results can 
be used to make informed design decisions and 
behavior of the trade-offs has been explained in [13]. 


6. Conclusion and Future Work 

We introduce the complex problem of DSM design 
decision-making and initial results of a modular tool 
being developed for the purpose. Future work includes 
integrating the tool into GSFC’s GMAT and make it 
python-based to remove the closed license dependence 
on STK and MATLAB. It will then be made freely 
available to all communities. 
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